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INTRODUCTION 


The purpose of this report is to document the midterm results 
of the Payload Software Technology Study performed by M&S 
Computing for the Marshall Space Flight Center under Contract No. 

NASS -32 047. 

During the completed part of this study, two main tasks were 
performed. First, a software analysis was performed of known STS 
sortie payload elements and their associated experiments. This provided 
basic data for STS payload software characteristics and sizes. Secondly, 
a set of technology drivers was identified based on a survey of future 
technology needs and an assessment of current software technology. 

During the remainder of the study, the results derived to date 
will be used to evolve a planned approach to software technology develop- 
ment. The purpose of this plan is to ensure that software technology is 
advanced at a pace and a depth sufficient to fulfill the identified future 
needs. 


This report is organized into seven sections as summarized in 
Table 1-1. Section 2 provides the executive summary and is adequate 
to obtain an overview of the results obtained to date. The sequence of 
the remaining sections generally reflects the sequence of tasks performed 
during this phase of the study. 
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MIDTERM REPORT OUTLINE 


SECTION I - INTRODUCTION DESCRIBES THE PURPOSE OF THIS REPORT, THE STATUS OF THE 
STUDY, AND THE MANNER IN WHICH THIS REPORT IS ORGANIZED. 

SECTION 2 - STUDY SUMMARY IS THE EXECUTIVE SUMMARY. 

2. 1 OBJECTIVES DESCRIBES THE PURPOSE AND SCOPE OF THE STUDY. 

2.2 APPROACH DESCRIBES THE STUDY PLAN USED AND THE ASSOCIATED MAJOR MILESTONES. 
2. 3 RESULTS SUMMARIZES THE RESULTS OF THE STUDY. 

SECTION 3 - PAYLOAD SELECTION DESCRIBES THE RATIONAL FOR SELECTION OF THE SPECIFIC 
COMPLEMENT OF EXPERIMENTS ANALYZED DURING THE STUDY. 

SECTION 4 - SPACE TECHNOLOGY FORECASTS REVIEW DESCRIBES THE IDENTIFICATION AND 
CLASSIFICATION OF SOFTWARE TECHNOLOGY AREAS SELECTED FOR EMPHASIS. 

SECTION 5 - EXPERIMENT ANALYSIS DESCRIBES THE APPROACH AND MATERIAL USED TO 
PERFORM THE EXPERIMENT ANALYSIS AND SUMMARIZES THE RESULTS. 

SECTION 6 - TECHNOLOGY DRIVER SELECTION SUMMARIZES THE TECHNOLOGY DRIVERS 
SELECTED AND THE REASONS FOR THEIR SELECTION. 

SECTION 7 - FUTURE PLANS DESCRIBES THE EFFORTS REMAINING TO BE PERFORMED UNDER 
THIS CONTRACT. 

APPENDIX A - MISCELLANEOUS 


APPENDIX B - SOFTWARE FUNCTIONS PROVIDES A COMPLETE DESCRIPTION OF THE DERIVED 
EXPERIMENT SOFTWARE FUNCTIONS AND THEIR SIZING PARAMETERS. 

APPENDIX C - EXPERIMENT ANALYSIS SHEETS CONTAINS SHEETS FOR EACH ANALYZED PAYLOAD 
ELEMENT AND THEIR ASSOCIATED EXPERIMENTS DESCRIBING MAJOR COMPONENTS, DATA 
CHARACTERISTICS, AND FUNCTIONS TO BE PERFORMED. 

APPENDIX D - SOFTWARE ANALYSIS MASTER MATRIX 


Table 1-1 
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STUDY SUMMARY 


This section provides a brief review of the study and a summary 
of the results to date. Section 2. 1 describes the intended objectives of the 
study. Section 2.2 explains the methods used. Section 2.3 summarizes 
the results. 

2. 1 Objectives 

The prime objective of this study is to define programmatic 
requirements for the advancement of software technology required to 
enhance future space applications. Future space applications are those 
planned or desired to be operational towards the end of the century. 

Although it is recognized that software technology requirements 
are likely to exist for ground as well as on-board facilities, the scope 
of this study primarily addresses on-board software technology. It is 
expected that a similar effort will be performed at a later date for ground- 
based software technology. 

The technology development plans resulting from this study must 
be implementable during the 19S0's in order to meet the requirements 
in the 1990's. It is assumed, for this study, that the primary development 
vehicle during this time will be the Space Transportation System. Therefore, 
payload analyses performed during this study will be limited to those payloads 
currently planned to be carried on the Space Transportation System. 

Finally, it should be noted that we are primarily concerned with 
so ftw are technology; not with computer systems technology. No attempt was 
made to analyze future Data Management Systems » as a whole, to drive 
out technology requirements. Such an effort certainly has merit, and might 
result in software technology requirements; however, many software 
technology requirements can be identified without an end-to-end data 
management analysis, and that is the road which we elected to follow. 

2. 2 Approach 

As shown in Figure 2-1, the study consists of three consecutive 
phases. The purpose of the first phase was to identify technology drivers, 
i. e. , major areas of concern and technology problems to be solved. Two 
types of analysis were performed during this phase: an analysis of a set 
of known experiments to identify significant software functions with their 
complexities and sizing; and, concurrently with that analysis, a technology 
survey was performed to identify the potential future technology needs of 
experiments. The results of these analyses are combined and summarized 
into a set of Technology Drivers. 
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During the second phase, these Technology Drivers are further 
analyzed to identify possible Technology Items. A Technology Item is 
an identified technology development program to resolve one or more 
aspects of a Technology Driver. 

Of course, alternate Technology Items may be identified for one 
Technology Driver. Also, the total number of Technology Items identified 
may be impossible to implement within the resource constraints. 

Therefore, during this phase, cost estimates and priorities are assigned 
to the Technology Items. 

The result of the third phase will be a recommended set of 
Software Technology Development Planning Guidelines. These are obtained 
through evaluation and selection of the most cost effective set of Technology 
Items. This selection depends upon cost, priority, interrelationships 
between the Technology Items, and dependencies on other technologies. 

Additional detail for each of these phases is provided in the 
appropriate sections in the remainder of this report. 

2. 3 Results Summary 

The set of Technology Drivers resulting from Phase I is listed 
in Table 2-1. At this point* the Technology Drivers associated with 
Software Development must be considered the most important. Unless 
significant improvements are made in this area, all other related 
technologies will be stunted because the associated software will be too 
costly and/or too unreliable. 

In Software Systems Architecture, most of the Technology 
Drivers are related to LSI technology; i. e. , the availability of very low- 
cost processing systems. These systems are particularly suitable for 
on-board usage and therefore receive significant emphasis during this 
study. 


The remaining Technology Drivers are primarily based on anticipated 
increases in on-board processing of image type data, as well as on antici- 
pated increases in the rates of data to be acquired. 

Some other conclusions that can be drawn from the results to date 
are the following: 

1. Currently planned experiments, with few exceptions, do not 

project a significant use of on-board data management 
system capabilities. 
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TECHNOLOGY DRIVER SUMMARY 


o 


o 


O' 

i 


o 


SOFTWARE DEVELOPMENT: 


SOFTWARE DESIGN ENGINEERING 

TREND TOWARD S/W DEVELOPMENT BY NON-t ROGRAMMERS 
FAULT- FREE SOFTWARE 

APPLICATION ORIENTED LANGUAGE DESIGN METHODOLOGY 
LOW COST DEVELOPMENT OF AOL COMPILERS 


SOFTWARE SYSTEMS ARCHITECTURE: 


(DISTRIBUTED) SYSTEM PARTITIONING/ 

INTERCONNECTION TECHNIQUES 

VERY LARGE STORAGE ACCESS SIMPLIFICATION 

SOFTWARE FAULT (OWN OR INDUCED) DETECTION 

SOFTWARE RECOVERY (AFTER FAULT DETECTION) 

HIGH-SPEED BUFFERING TECHNIQUES 

DESIGN AND CONTROL OF ADAPTIVE SOFTWARE 

PROCEDURES. 


SOFTWARE APPLICATIONS: - USE OF "NATURAL" COMMUNICATION METHODS 

- EFFICIENT LARGE ARRAY SEARCH AND SORT PROCEDURES 

- PARALLEL PROCESSING TECHNIQUES 

- EFFICIENT LARGE ARRAY MANIPULATION PROCEDURES. 


Table 2-1 


t 


> 


This is to some extent due to the known limitations of the 
Baseline Spacelab-Data Management System, but probably 
even more so it is due to traditional approaches and/or 
fears of integration problems. It does point to a significant 
"application technology gap" between computer system usage 
in the early 80* s and what is anticipated to be needed in 
the 90’ s. 

2. The currently planned Spacelab Data Management System is 
not adequate for technology development. 

Because various cost constraints have been imposed on 
Spacelab, the data management system is relatively limited 
in its capabilities. This became obvious as we analyzed 
potential uses of on-board software. These limitations will 
probably not be of significance during support of the early 
years of flight, but the limitations will create a major 
shortcoming in the late 80* s because of the constraints 
placed on technology development. 

3. No "esoteric" software technology requirements were 
identified. 

No surprising requirements were uncovered during the first 
phase of the study. Nevertheless, it will not be a simple 
effort to derive an effective technology development plan. 
Many of the significant requirements have been under study 
before, and technology advancements have been previously 
attempted with little tangible success. The real key to 
satisfactory results from this study will lie in the recognition 
of imaginative, realizeable technology development items. 
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3. PAYLOAD SELECTION 

The purpose of this task was to select applications which, through 
analysis, could yield information relevant to this study. Advanced space 
missions are currently not defined in sufficient detail to allow relatively 
quick identification of software technology development requirements. 
Therefore the emphasis of this study is on potential subsets of future 
payloads, i. e. , payload elements. 

Certain practical criteria were established to guide the initial 
payload selection process. These were: 

o Data availability. 

o U. S. experiments only. 

o Broad instrument mix and varied output forms.- 

To obtain broad coverage, the Shuttle Sortie Payload Descriptions 
(July 1975), Level B, were selected as the starting point. Data availability 
for these payload elements is still a- major problem but a portion of the 
problem was resolved during the subsequent task through various means 
such as comparison to similar instrumentation types, extrapolation of data 
rates for increasing resolution criteria and surveys of state-of-the-art 
detectors and sensor technology. 

The payload elements which were analyzed in sufficient detail to 
yield useful data are listed in Table 3-1. 
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PAYLOAD ELEMENTS 

Payload 
Element No. 

Name 

AS-01-S 

1M Shuttle IR Telescope Facility 

AS-03-S 

Deep Sky UV Survey Telescope 

AS-04-S 

1m Diffraction. Limited UV-Optical Telescope 

AS-05-S 

Very Wide Field Galactic Camera 

AS-15-S 

3m Ambient Temperature IR Telescope 

AS-63-S 

Sortie Medium Aperture Optical Telescope 

HE-ll-S 

X-Ray Angular Structure 

HE-15-S 

Magnetic Spectrometer 

HE-19-S 

Low Energy X-Ray Telescope 

HE-25-S 

Transition Radiation Detector 

so-oi-s 

Dedicated Solar Sortie Mission 

SO-ll-S 

Solar Fine Pointing Payload 

SO-15-S 

Solar Activity Early Payload 

SO-17-S 

Solar Activity Growth Processes 

AP-06-S 

Atmospheric, Magneto spheric, and Plasmas in Space 

AP-08-S 

LIDAR System 

AF-09-S 

Electron Accelerator 

AP-10-S 

Chemical Release 

AP-ll-S 

Diagnostic Payload 


Table 3-1 
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PAYLOAD ELEMENTS 


Payload 
Element No . 

AF-12-S 

AP-13-S 

LS-04-S 

LS-09-S 

LS-10-S 

LS-13-S 

EO-Ol-S 

EO-05-S 

EO-06— S 

EO-19-S 

EO-20-S 

EO-21-S 

EO-22-S 

OP-02-S 

OP-03-S 

OP-04-S 

OP-05-S 

OP-06-S 

*SP-01-S 


Name 

Throw-Away Detector Satellites 

Low Light Level TV 

Free-Flying Teleoperator 

Life Sciences Shuttle Laboratory 

Life Sciences Mini -Laboratory 

Life Sciences First US/ERO Spacelab Mission 

Zero G Cloud Physics Laboratory 

Shuttle Imaging Microwave System 

Scanning Spectro radiometer 

Mark II Interferometer 

Earth Resources Shuttle Imaging Radar 

Shuttle Imaging Microwave System 

Mark II Interferometer - Earth 

Multifrequency Radar Land Imagery 

Multifrequency Dual Polarized Microwave Radiometery 

Microwave Spectrometer 

Multispectral Scanning Imagery 

Laser Altimeter /Frofilixneter Experiment 

SPA No. 1 - Biological (Manned) Laboratory 

Table 3-1 (Continued) 
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PAYLOAD ELEMENTS 


Payload 
Element No. 

*SP-14 -S 

*SF-15-S 

SP-31-S 

ST-08-S 

ST-31-S 

CN-04-S 

CN-OS-S 

CN-08-S 


Name 

SPA No. 14 - Maimed/Automated Laboratory 

SPA No. 15 - Automated Furnace/ Levitation 

First Spacelab Mission (Biological and Furnace 
Subelements and Core) 

Integrated Real-time Contamination Monitor 
Drop Dynamics 

Electromagnetic Environment Experiment 
CO 2 Laser Data Relay Link 
T¥T Open Envelope Experiments 


Table 3-1 (Continued) 


4. 


SPACE TECHNOLOGY FORECASTS REVIEW 


It was recognized early that analysis of payload elements by itself 
would uncover only a limited set of technology drivers. Concurrently with 
the experiment analysis, a technology survey was necessary to uncover 
additional technology drivers. During this survey, the identification of 
technology emphasis areas (i. e. , broad identifications of problem areas) 
was the main goal. These areas are subsequently analyzed for technology 
drivers as described in Section 6, Technology Driver Selection. 

The major publications reviewed are listed in Table 4-1. The main 
emphasis was placed on the Outlook for Space and the OAST workshop results. 
The publications provide technology requirements on various levels: from 
a very broad identification of areas of interest, to specific recommendations 
on technology development items. The air of the review was to summarize 
the indicated technology areas specifically enough to provide clear direction, 
but broadly enough not to prejudice the results of the study. 

4. 1 Software and Software Technology 

In pursuing the goals of this study, certain definitions and under- 
standings are necessary to communicate the software roles and needs in the 
systems being analyzed. 

A data system is considered to be made up of hardware, software, 
and mathematical {or system logic) elements. Software represents the 
enabling mechanization of the desired mathematics or logic functions on 
the computing hardware of that system. Systems concepts may require 
certain mathematical functions to be performed on data being processed by 
the system; however, these functions are not software, per se, but rather 
are inputs to the software process. 

Software technology is, therefore, that technology which converts 
mathematical or logic requirements into computer programs that can 
operate on the available computer hardware. Software technology advance- 
ments will be required wherever hardware, space, processing time, or 
resources in general impede or limit this desired conversion. 

4. 2 Payload Scenario 


The 1980-1990 payload scenario characteristics which drive the 
payload software technology requirements can be summarized as follows: 

High data acquisition rates are probably the main driving 
force behind the technology requirements. This reflects 
more data per payload, as well as an increased number of 
concurrently active payloads. 


o 


REVIEW OF TECHNOLOGY FORECASTS |j 

PRIME REFERENCES . « 

I 

1. OUTLOOK FOR SPACE, JANUARY 1976. 

2. A FORECAST OF SPACE TECHNOLOGY 1980-2000, JANUARY 1976. 

3. OAST SPACE THEME WORKSHOP, APRIL 1976 (QUICK- LOOK 
COMMENTS AND WORKING PAPERS). 

4. SPACE ELECTRONICS TECHNOLOGY SUMMARY, MARCH 1976. 

5. OAST SUMMARY WORKSHOP, AUGUST 1975. 

6. INFORMATION PRO CESSING/ DATA AUTOMATION IMPLICATIONS 
OF AIR FORCE COMMAND AND CONTROL REQUIREMENTS IN 
THE 1980’s (CCIP's), 1975. 

7. FINDINGS AND RECOMMENDATIONS OF THE JOINT LOGISTICS 
COMMANDERS SOFTWARE RELIABILITY WORK GROUP, NOVEMBER 
1975. 

8. KEY DEVELOPMENTS IN COMPUTER TECHNOLOGY: A SURVEY, 

IEEE COMPUTER MAGAZINE, NOVEMBER 1976 (LATE INPUT), 


Table 4-1 
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o Increased utilization of software is a logical consequence of 

the increased sophistication of space systems and the 
availability of relatively low-cost, minaturized processor 
hardware. 

o Real-time user-aystem interaction is dictated to perform 

the real-time data selection and the systems control 
required to effectively apply the planned operational systems. 

o Increased systems autonomy is dictated through an increased 

emphasis on unmanned exploration, as well as the need to 
decrease the manpower cost required to support long-duration 
missions and operational systems. 

o Data and facility sharing networks are visualized to prevent 

a duplication of large processing and very large storage 
facilities for data common to many diverse users. 

4. 3 Software Technology Categories 

To present the information in a somewhat digestible form and to 
eventually be able to group related development items, three categories of 
software technology were established: 

o Software Development Technology includes those areas 

associated with the project management, design, implemen- 
tation, testing, verification and validation of software in 
general. 

o Software Systems Architecture contains those areas con- 

cerned with software system structures and attributes 
required to fulfill general systems concepts and capabilities 
not solely associated with specific applications. 

o Software Applications Technology encompasses those areas 

related to certain broad classes of applications which operate 
and control experimental or operational equipment. These 
areas are, thus, specifically driven by the type of planned 
space applications more so than any other category. 

4. 4 Software Emphasis Areas 

The review resulted in the identification of 16 emphasis areas. Some 
of these do not directly affect on-board software technology, and are not 
directly analyzed for technology drivers. These areas are indicated by 
asterisks in the following summary. 
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4.4. 1 Software Development Technology 

Technology emphasis in the software development category is prime 
to any other significant software technology advancement. Lack of adequate 
development technology is perhaps the most significant deterrent to 
increased degrees of automation. Technology areas recognized are: 

o Cost/time reduction methods. 

o Software reliability. 

o Cost/performance evaluation. 

o Software /hardware standardization. 

These technology emphasis areas are not unique to space systems; 
however, the last two carry far more significance for space applications 
than for most groundbased systems. 

4.4.2 Software Systems Architecture 

This category contains most of the technology emphasis areas 
identified and is indicative of the quantum jump in software utilization 
for the 1980-1990 space applications. This quantum jump is made feasible 
by the fantastic pace at which processor hardware technology has progressed. 
The following areas of emphasis were identified. 

o Functional distribution of processing. 

o Fault tolerance systems. 

o Intelligent instruments. 

o Human/System interfacing. 

*o Utilization of high-rate data processors. 

*o Data distribution/ sharing networks. 

=rO Very large data base management. 

*o Multidimensional data base systems. 

It is noticeable that many of these areas are interrelated with the 
hardware or systems technology they are to operate with. 


4. 4. 3 Software Application Technology 

The line between software technology and other data management 
system technologies is even more difficult to draw for the emphasis areas 
identified here. 

o 

o 

o 


Image processing and pattern recognition. 
Data compression. 

Automated intelligence. 

Automation of ground -support functions. 
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5. 


EXPERIMENT ANALYSIS 


Experiment analysis is a basic element of the Payload Software 
Technology Study. An understanding of instrument function and data 
characteristics is required to identify those parts that go beyond the 
state-of-the-art of software/ system technology and, consequently, 
comprise the technology drivers. 

This section describes the approach and material used to perform 
the experiment analysis and summarizes the results. 

5. 1 Objectives 

Five specific objectives were established for the experiment analysis 
activity of Phase I, These are: 

o Identify significant processing functions associated with 

STS payloads. 

o Identify "next generation” on-board processing functions. 

o Determine data management system technology drivers. 

o Assess software development load. 

o Provide the basic method and data for future experiment 

software analysis. 

Significant processing functions are those payload oriented functions 
which drive resource utilization into the margin or beyond the capability of 
currently defined data management systems. The basic resources against 
which the processing functions were measured are: 

o Processor main memory. 

o Processor speed (in equivalent adds per second). 

o Input/output data. rate. 

o Mass memory capacity. 

o Display capability. 
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The 11 next generation." oa-board processing functions are those that 
will be added (or transferred from ground systems) to accelerate the 
accumulation and distribution of more and higher quality data to the end 
user, at reduced cost, and within the physical limitations of bandwidth, 
ground handling, and archival facilities. 

Data management system technology drivers are those functions 
which are mandatory to enable a mission, enhance a mission, and/or 
reduce overall cost, but for which new technology must be developed. 

Some of this technology is pure hardware, and a lesser amount is pure 
software, but the major part is system technology which synthesizes the 
complementary hardware/ software attributes into an optimum mix of 
cost, convenience, and rate of return. 

Assessment of the software development load covers the 1980-1990 
time frame. The purpose of this objective is two -fold - : 

o Bound the software development facility requirements’. 

o Reveal areas in which software development technology 
items could improve software reliability and reduce 
development cost. 

The last objective is to provide the form and structure of a data 
base that would be required to relate software function to experiment, 
to provide a simple tool for combining experiment loads into payload 
element loads, and payload element loads into mission loads, while 
retaining the flexibility to add new software functions and new experiment 
or payload elements without structure redefinition. 

5. 2 Scope 


Experiment analysis includes the evaluation of currently defined 
experiments, pre -operational and operational prototype systems, and 
encompasses those end-of-the-century operational space system goals 
established by NASA and the scientific/ industrial community. The scope 
is depicted in Figure 5-1. 

The first few years of Shuttle Operations are based on currently 
defined payloads which are primarily payloads or improvements to payloads 
that have flown before. The main thrust of this period will be toward 
sensor development. 

The pre-operational and system prototype periods will encompass 
the development and testing of new concepts and new techniques to enable 
digestion of orders of magnitude increases In data at drastically reduced costs. 
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The operational phase entails full implementation of long-life, 
production-oriented satellites and space stations. Routine repair and 
refurbishment in space will be common activities. Preprocessing by 
the data collection systems, coupled with final processing and direct 
distribution of the finished product from space stations, will greatly 
enhance space utilization and reduce traffic to and between ground 
facilities. Concepts and technologies developed during the early years 
of STS will directly affect the utility and cost of future systems. 

5. 3 Experiment Analysis Task Flow 

The experiment analysis task flow is shown in Figure 5-2. The 
task consists of two parts: (1) payload element analysis, and (2) software 
function analysis and sizing. These parts are integrated into the Software 
Analysis Master Matrix (SAMM) from which is derived the Data Management 
System concepts and software development sizing analysis for the 1980- 
1990 STS era. 

The July 1975, Level B, SPDA was chosen as the model from which 
payload elements and instrument descriptions would be extracted for the 
technology study. Other data pertinent to these selected items was fed into 
the flow to add a greater level of detail. This data included: 

o Payload definition studies. 

o Integrated Mission Analysis Planning (IMAP). 

o User's Information. 

o Previous Programs. 

o Previous Studies. 

o In-house Expertise. 

5. 3. 1 Payload Element Analysis 

Payload element analysis consisted of the collection and classification 
of payload element/ experiment data specific to payload software. A 
compressed form (Figure 5-3) was developed to provide a visible, compre- 
hensive source for future analysis tasks. 

Each payload element contained in the Level B SPDA was broken 
into individual experiments. The experiment number, objective and instrument 
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characteristics, the instruments) required, and sensor type were entered 
onto the payload element analysis form. Sensor /detector requirements 
were identified, including spectral range, bandwidth, sensitivity, and other 
distinguishing features leading to the characterization of the data produced. 

The payload element analysis was completed with the identification 
of software functions applicable to each specific experiment. 

With this approach, 42 payload elements containing 2 14 experiments 
were analyzed and the resulting data was entered onto the payload element 
analysis sheets. 

5.3.2 Software Function Analysis 

The software function analysis consisted of identification of standard 
software functions, a function description, and baseline sizing data. This 
information is contained in the software function sheets, a sample of which 
is 3 hown in Figure 5-4. Thirty-nine functions have been identified and 
described. Each has been assigned a standard name and identification 
number for subsequent use on the SAMM matrix. 

Early in the study, it was determined that many experiments, 
although different in nature, shared common software functions. Due to 
independent development and lack of standardization, these common functions 
were often overlooked in the past because of different names for the same 
function or because slightly different algorithms accomplished the same end. 
This study attempts to bring standard functions into view. For instance, 
a Fourier transform as applied to an interferometer is no different than a 
Fourier transform as applied to data compression. 

The software function descriptions and sizing do not extend to standard 
operating system functions. " They are strictly experiment- control /monitor/ 
scientific -data oriented. 

The sizing of a software function is based on a typical application which 
is spelled out in the function description where applicable. The sizing criteria 
centers on main memory requirements, processor speed in equivalent adds 
per second (EAPS), and input/output volume and rate. For a given function, 
the number of instructions remains fairly constant; therefore, the main 
memory requirement is basically dependent on the size of the I/O buffers. 
Processor speed is dependent on the number of data words to be processed 
in a given amount of time. In either case, the prime variables are the number 
of words per I/O sample and the sample rate. Provision has been made in the 
SAMM matrix to adjust sizing values because the prime variables change from 
application to application. 
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SOFTWARE FUNCTION 


401 Calibration (Simple Detectors) 

Calibration on a one-time-per-mission basis requires operation of the experiment with 
known reference sources. These may be black-body sources, light sources, or known values of 
voltage, current, radiation, and other standards. The output of the sensor/detector is used to 
generate calibration curves/values with which to modify or correct the source data of interest 
during operation of the experiment. 
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5. 3. 3 SAMM Matrix 


The SAMM matrix (example shown in Figure 5-5) provides a means 
of correlating experiments to software function. It was designed to provide 
an input to an automated data base application should the need arise in 
future study activities. 

The vertical columns contain a sequential list of payload elements, 
further subdivided into experiments. In many cases, the experiment 
element serves as an experiment facility (as in AS-01-S); therefore, all 
functions common to the facility are allocated at the payload element level, 
and experiment-unique functions are allocated at the experiment level. 

The horizontal columns contain the 39 identified software functions. 
The design intent is that the sizing for each software function would become 
a part of the data base mentioned above, and thus permit the summing of 
experiment loads into payload elements and payload element loads into 
payloads. 

In the sample matrix, black dots at the matrix intersections indicate 
the software functions that apply to a given experiment or payload element. 
Should the automated data base be generated, these dots would be replaced 
by numbers representing a complexity factor to be multiplied times the 
sizing data for a given function. The complexity factor (or multiplier) would 
be dependent on the I/O volume and rate (i. e. , words per sample and sample 
rate). This approach allows broad flexibility in the combining of payloads 
and calculating the resulting data management system requirements. 

Mass memory requirements have not been specifically discussed in 
the sizing criteria; however, a capacity of 100 million bits will support any 
experiment or payload element evaluated. The overriding considerations 
with mass memory are that it should provide rapid random access and 
read/write capability. 

5. 4 . Results Summary 

Experiment analysis did not generate any real surprises. It did 
tend to confirm what had here-to-for been intuitively understood. In general, 
the findings were: 

o Currently planned on-board software functions generally do 

not exceed planned data management system capabilities 
(possible exception is AMPS). 
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o "Next generation." on-board software functions can generally 

not be accommodated within planned data management system 
capabilities. 

o Current generation experiments rely heavily on film. Future 

generations will use more and more Vidicons and CCD's for 
data collection. 

o Prime software technology emphasis areas are: 

Pattern Recognition. 

Image Processing. 

- Data Compression. 
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TECHNOLOGY DRIVER SELECTION 


In this task, the technology emphasis area Identified in Section 4, 

Space Technology Forecasts Review, and Section 5, Experiment Analysis, 
are farther analyzed to identify the associated Technology Drivers. This 
section summarizes the results of that effort. 

To ensure a clear understanding, we must first clarify the meaning 
of the term "Technology Driver." Technology is generally defined as the sys- 
tematic knowledge of, and its application to, industrial processes. A Tech- 
nology Driver is, then, an incentive, a need to obtain this systematic knowl- 
edge, or apply available systematic knowledge to an industrial process. In 
other words. Technology Drivers are, simply, problems for which a solution 
is desired and needed. The idea(s) put forth to solve the problem are, what 
we call in this study, Technology Items. 

Problems, and therefore Technology Drivers, can occur on many levels 
of detail. For example, the need for a more efficient method of programming 
computers {the Technology Driver) resulted in the idea (Technology Item) for 
the use of higher order languages. Subsequently, the use of high order lan- 
guages presented an efficiency problem (the Technology Driver), resulting in 
development of optimization techniques (the Technology Item). 

Also, a problem may have several aspects, thus requiring multiple, 
related Technology Items; or it may have several possible solutions, thus, 
again, resulting in multiple Technology Items. 

The technology emphasis areas described in Section 4 were divided 
into three categories. In this section, the results of the analysis are described 
in accordance with those categories. It should be noted, however, that the 
Technology Drivers do not necessarily fall within the same category as the 
associated emphasis area. For example, a technology emphasis area within 
the category of software system architecture may point to a Technology Driver 
associated with the category of software development. The summary pres- 
ented in Section 2. 3, Results, lists the Technology Drivers in the appropriate 
categories as they were recategorized subsequent to the Technology Driver 
Section discussed here. 

6. 1 Software Development 


During the review of Software Development Technology, two major 
points recurred in various guises; 

o There is no facet of software development that is considered 

to be satisfactorily performed in a production mode. That is. 
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major shortcomings are identifiable in every step of the devel- 
opment process ("With the possible exception of coding). There 
is a general feeling of inadequacy, dissatisfaction, and a lack 
of confidence in the merits of proposed solutions. 

o There have been only two major breakthroughs in the history 

of software development. The first one was the use of higher 
order languages, and the second was the identification of struc- 
tured programming techniques. The former is now practically 
and generally implemented and has resulted in tangible improve- 
ments. The latter is only sporadically applied and, therefore, 
is not yet generally used in a production mode. 

Almost every facet of software development can, therefore, be a Tech- 
nology Driver. Further investigation into the problems, proposed solutions, 
and status of technology development revealed, however, a common cause of 
difficulties. The key to this common cause is the lack of Software Design 
Engineering technology, Software Design Engineering is conceived to cover 
interpretation of requirements and creation of a design, but not the physical 
implementation of the software. 

This software design problem is an even more difficult problem in the 
area of payload software than it is in most other areas. Payload Software is 
generally part of an "embedded" system, that is, a computer system that is 
only part of, and integrated into, an equipment complex such as an avionics 
system. The software design problem itself is difficult enough, but in the 
"embedded" system, these difficulties are multiplied by the external constraints 
imposed by the total system. 

We will not try to describe here all the facets of Software Design; 
however, some of the issues are discussed below; 

o Visibility of Design; for example, how early in the cycle can 

a design be made visible so that proper planning can be per- 
formed? How should a software design be described so that 
is provides sufficient direction for the next level of design 
or so that is can be evaluated against level of design? (Note 
that a design becomes a requirement for the next lower level 
of design. ) This brings us to the even more basic questions 
of: what should be specified in a software requirements docu- 
ment, what is really essential, and how it should be described? 

How is traceability maintained? There are, or course, many 
other questions. 

o Design Techniques; for example, how should a software sys- 

tem be structured to be manageable? . .PTestable? "....Modifiable? 
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It is generally believed that no hard and fast rules can be 
derived. We are therefore looking for principles that can be 
applied to a specific system, to derive the rules and standards 
for a particular project. Furthermore, they must be usable 
in a normal production environment. 


0 


D 


u 


o Design Evaluation; for example, how can a design be realisti- 

cally evaluated before the full implementation is started? 

Assuming that we can describe the design and have used sound 
principles of design, how can we establish that the physical product j~~j 
will be satisfactory? A satisfactory software produc*. must have 
desirable qualities with respect to its man-machine interface; 
it must be relevant to the system functions it purports to serve; 
and it must be reliable in its operation. 

As can be seen from such issues. Software Design Engineering has 
multiple interrelated facets. Current and past technology developments 
have primarily addressed the development cycle from the point that a com- 
plete design specification is available. Some effort has been made in forma- 
lizing the design specification (Ref. Table 6-1); however, only recently has 
recognition been given to the fact that all successes and failures of systems start 
with the proper design p rinc iples or lack thereof. The interrelationships between 
these facets are not yet well understood. 

We made an attempt to subdivide Software Design Engineering into 
multiple Technology Drivers. However, because this area is so und eveloped, 
this seemed to be presumptuous. We have to analyze /under stand Software 
Design Engineering as a whole before we can see and develop the parts. 

6. 2 Software Systems Architecture 

Within this category are grouped those areas concerned with software 
system structures and attributes required to fulfill general system concepts 
and capabilities not solely associated with specific applications. 

Note that this technology is closely associated with other technologies 
that relate to the system as a whole. This is particuarly true of onboard data 
management systems where the computer and its software have a more 
subordinate role than in most groundbased computer applications. 

Four emphasis areas were previously identified within this category 
which could affect onboard processing: 


o Functional distribution or processing, 

o Fault . Tolerant Systems. 
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o 


Intelligent instruments. 


o Human- system interface. 

The area of "Intelligent Instruments" turned out to be a subset (as far f 

as its software implications are concerned) of the more general area of "Func- 
tional Distribution of Processing" and is therefore not analyzed by itself. Jj 

The remaining areas are each briefly discussed in the following 
paragraphs. j 

6.2. 1 Functional Distribution of Processing 

A distributed system, as the term is used here, it a system which - 

contains multiple processors, each with its own executive, performing dedi- 
cated functions as part of a single partitioned system, usually each housing 
its own main memory. The concept is not particularly novel. However, it 
is only recently, through the advent of microcomputers, that is has become 
eminently practical. 

A distributed system has two major advantages, within the context of 
this study: 

1. Simplified development /modification of the system. 

2. Ability to perform parallel processing. 

Simplified development/modification of the system comes about through 
the relative independency of the subsystems. That is, the computer process 
becomes a more integral part of the subsystem it is assigned to and thus it 
can be designed, adapted, and verified almost independent of the other subsys- 
tems. Particularly note, however, that the system design as a whole does not 
become any simpler, only more flexible. The very flexibility may make the 
system design, or the choice of system design, more difficult. Any network 
of computers has, for the software as well as the hardware, the inherent prob- 
lem of selecting interprocess communication techniques and selection of func- 
tions to be or not to be distributed. This is, generally, an ill -defined area. 

It thus results in a Technology Driver entitled "System Fartitioning/Interconnection 
Techniques. " 

The ability to perform parallel processing is of particular advantage 
in "hard real-time" systems such as process control systems and payload 
control systems. These systems are often characterised by the requirement 
to very rapidly respond to randomly (and therefore possibly simultaneously) 
occurring external events. This is classically a major problem in the use of 
centralized systems and often becomes a trivial problem in distributed systems. 




The availability of low-cost processors has, in fact, a stronger effect 
than just the distribution of processes that previously were performed in a 
central processor. It has the additional effect of "computerizing" processes 
that previously were hardwired. This is particularly noticeable in current 
instrument development. A natural consequence of this intensified usage 
of computers is that an increasing number of programs are being written by 
engineering personnel rather than professional programmers. This elimi- 
nates the problems associated with the classical engineer /programmer 
communication gap, but forces a significant need for truly user -oriented 
software development systems and methods. This trend toward software 
development by non-programmers must therefore be considered a Technology 
Driver, 


A hardware technology that is associated with the availability of low- 
cost computers, but currently lagging, is the availability of low-cost, large, 
rapid-access storage. Accessing such memories and using them effectively 
is currently a specialized software area. To enable engineering personnel 
to use such storage devices on a routine basis requires some method of 
simplifying the use. This is another Technology Driver. 

To summarize, "the Functional Distribution of Processing Technology" 
emphasis area has three Technology Drivers directly associated with it: 

1. System partitioning/interconnection techniques, 

2. The trend toward software development by non-programmers. 

3. Very large storage access simplifications. 

6. 2. 2 Fault Tolerant Systems 

The most all-encompassing definition of a fault tolerant system is that 
which is normally used in the EESE publications: "A Fault Tolerant System is 
a system that has the ability to execute specified algorithms correctly, regard- 
less of hardware failures, system flaws, or program fallacies. ,T 

This has been a fascinating, much-studied subject for a considerable 
period of time. There is, however, no system in existence that completely 
meets the definition, and, in fact, one may never exist. Nevertheless, a 
close, cost-effective approximation of such a system may filfill a real need 
for many applications. 

A major stumbling block for many designs has been the high cost of 
the redundant hardware which is a basic requirement for such a system. This 
stumbling block is now being removed through the current advances in LSI 
technology. 
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The ideal fault-tolerant computer system would be a system in which 
hardware failures are totally maskedJby instantaneous correction. Assuming 
that such a system is technically feasible, the next stumbling block, is the low 
reliability of the software. Minimizing the number of faults that are intro- 
duced into the software is a developmental problem that has been previously 
addressed under that category (Section 6. 1). What we are concerned with is 
proving that there are no software faults left in a particular software package. 
As this is still beyond the state-of-the-art, it must be considered a Technology 
Driver. 

It may, for various reasons, never be truly feasible to provide absolute 
proof of software correctness. It therefore behooves us to study an alternate 
means of preventing the software from causing a system, failure. This 
approach is detection of software failures during execution. It is not clear 
if and how this is truLy feasible; nevertheless, it is the only currently known 
alternate and must therefore be listed as a Technology Driver. 

Associated with the problem of fault detection is the problem of fault 
correction and recovery. In many hardware schemes, and in all known soft- 
ware schemes of fault detection, one or more instructions have been executed 
by the time a fault is detected. Recovery from such unwanted instruction 
execution is still an unsolved problem and must therefore still be considered 
a Technology Driver. 

_ To summarize, there are three highly significant software Technology 
Drivers associated with the feasibility of fault-tolerant systems: 

1. Fault-free software. 

2. Software fault detection. 

3. Software recovery. 

6. 2. 3 Human/System Interface 

This area is concerned with the ease and effectiveness of the commu- 
nication of instructions and information between humans and computer systems. 
This has been a fruitful area for technology development for a long time, and 
it remains to be a high-priority emphasis area. 

As noted in the above paragraph, two distinct types of interfacing can 
be distinguished. The first one deals with the, essentially one-way, commu- 
nication that takes place when a user is instructing, i.e», programming, the 
computer. The second one deals with the interaction which may take place 
between a human and a computer system as the system is executing an 
application. 
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With the increased utilization of computers, a new type of user, i. e., 
the non-programmer, is starting to dominate software development (as pointed 
out in Section 6.2. 1), With this, a shift to an increased emphasis on applica- 
tion-oriented languages (as apposed to General-Purpose Higher Order Languages) 
must be anticipated. Language design is one of those typical software areas 
which have no real guidelines, standards, or evaluation criteria which can aid 
in the quick development of high order languages. Language design is fre- 
quently a costly process of long duration. Therefore, the development of an 
application-oriented language design methodology must be considered a 
Technology Driver. 

A compiler i9 needed for each language which will be designed and for 
each computer the language will be used for. Although considerable research 
and development effort has been expended, compilers remain as very expen- 
sive items. The potential proliferation of languages and computer systems 
obviously requires that these developmental costs be decreased significantly. 

This Technology Driver, in this context, is separately identified, but actually, 
it is closely related to the preceding Technology Driver. 

We will not elaborate here upon the need for and uses of interactive 
communication between users and computer systems. This has been well 
described in many other publications. We believe, however, that spaceborne 
applications are more likely to need more "natural" interactive communication 
methods than most groundbased applications. This belief is based on the 
severe constraints placed on numbers of personnel, time, utilization, train- 
ing, etc., for manned space vehicles. Much emphasis is being placed, within 
the industry, on the development of interactive methods. The technology 
driver, as fas as NASA is concerned, is the development of more natural 
communication methods, such as voice, patterns, etc., which can complement 
industrial developments. 

To summarize, the Technology Drivers within this emphasis area which 
are of particular importance to spaceflight are: 

1. Application-oriented language design methodology. 

2. Low-cost development of AOL compilers. 

3. Use of "natural" communication methods. 

6. 3 So ftw are Applications 

The software applications category encompasses those areas which 
operate and control experimental or operational equipment. These areas 
are driven by the type of planned space utilization more so than any other 
category. 
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The natural emphasis has been on the feasibility of onboard implemen- 
tation of the state-of-the-art software available foh these applications. Each 
application area calls for a unique set of software functions. However, some 
of these functions are common to more than one application area and repre- 
sent a set of basic functions which are performed onboard; for example, the 
functions associated with monitor, control, sequencing, and other housekeep- 
ing chores. Other functions are more specialized but still need to be performed 
onboard (such as pointing control, reference frame transformation, and scanning 
control). There are yet other functions which could conceivably be performed 
onboard, depending on cost/benefit ratios. Some typical functions belonging 
to this category are pattern classification, image enchancement, registration 
and geometric correction, and filtering and noise removal. 

Three emphasis areas have been previously defined within this category 
that could affect onboard processing: 

o Pattern recognition and image processing. 

o Data compression. 

o Automated intelligence. 

6. 3. 1 Pattern Recognition and image Processing 

This encompasses all the necessary processing involved in deriving a 
classified (recognition) map which has been geometrically corrected to fit a 
reference map (or image). Generally, this involves processing of multi- 
dimensional data such as those obtained from multispectral scanners and, 
consequently, the computational demands are far more severe. 

The classification or recognition activity involves three distinct phases: 

o Feature selection. 

o Learning. 

o Classification or labeling. 

Each phase involves a variety of software functions, the choice of which 
is heavily dependent on the data environment and its characteristics. This is 
illustrated for a few typical cases in the Data Environment Scenario versus 
Software Function Matrix depicted in Table 6-2. A study of this matrix and 
underlying concepts shows that classification, which is repetitively deployed 
to derive the labels of all the input data samples, is the single most important 
and common function. Accordingly, optimization of the computational needs 
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of this phase is of considerable significance in the context of the constraints of 
onboard processing. The actual classification method to be employed depends 
to a large extent on the data environment. Some of the commonly encountered 
classification concepts are "the nearest neighbor," "maximum likelihood," 
and "linear and piecewise linear." There are, of course, numerous variations, 
both conceptual and computational. A commonly employed computational alter- 
native is the so-called "table lookup" approach which is based on a trade-off 
of memory versus computational time. It should be noted that, actually, the 
table lookup approach is not an independent classification method, but only an 
implementation scheme which can be used in conjunction with the maximum 
likelihood concept or any other parametric classification concept. Table 
lookup schemes appear feasible only for relatively low resolution or limited 
channels because of the memory requirements associated with this approach. 

This problem may be overcome by a recently proposed alternative 
table lookup scheme, wherein only the table corresponding to a set of prototypes 
need by stored. These prototypes are derived through a multidimensional 
histogram analysis. However, in this histogram analysis process, the 
critical factor is the CPU time. This is mainly due to the associated large 
array search. Therefore, crucial to the onboard implementation of many of the 
software functions associated with pattern recognition and image processing 
activities, is the need for efficient software procedures for performing large 
array searches and sorting, which is accordingly viewed as a software Technology 
Driver. In addition, the classification processing of individual picture elements 
or samples can be carried out independently for each pixel and hence there is 
a natural incentive for considering parallel processing as a means of reducing 
the computational demands of this function. This can be achieved by restructurin 
and/or modifying the presently available software towards obtaining the maximum 
benefits of parallel processing. Parallel processing techniques are also viewed 
as an important Technology Driver arising from this emphasis area. 

In another area of pattern recognition and image processing, the pro- 
cess of correcting the image to fit a reference map or frame of coordinates 
must be considered. This process involves two major software functions: 
registration, defined as the task of deriving the transformations (rotation, 
translation as scale changes) needed for obtaining the best fit; and geometric 
correction, defined as the task of applying these transformations to derive 
the transformed or corrected image. These operations, especially registra- 
tion, involve a certain amount of human interactions. The high computational 
loads associated with the geometric correction function can again be viewed as 
a problem calling for more efficient large array manipulation procedures. Also, 
viewing the large image as a set of smaller images, the advantages of parallel 
processing may be realized. 

In summary, the software Technology Drivers associated with the area 
of pattern recognition and image processing, are; 
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o Efficient large array search and sort procedures, 

o Parallel processing technique s. 

6.3.2 Data Compression 

Both the Outlook for Space (OFS) report and, to a greater extent, the 
OAST Summer Workshop Data Processing and Transfer report recognize the 
key role of data compression technology in the advancement of the state-of- 
the-art space -related information management systems. In particular, 
imagery data from a variety of multispectral scanners, as well as radar 
experimental packages, are expected to dictate the demand levels to be met 
by these systems. Of course, each application calls for a different minimum 
level of fidelity in the data as it is received on the ground. Neglecting, for 
the present, communication channel (downlink) noise, and considering only 
the fidelity in terms of level of detail required in the data by the different 
applications, at least four distinct categories of applications can be identified 
as those requiring: 


Category 1: Exact reconstruction of the multispectral imagery at 

each point or picture element (pixel) in each of the 
scanned frequency ranges. 

Category 2: A good approximation of the imagery at each point and 

in each frequency range with little visually perceptible 
degradation. 

Category 3 : A single recognition map (derived by, say, multi- 

spectral classification onboard of the scanned imagery 
data) which leads to lower data rates as compared to 
transmission of the entire set of raw multispectral 
imagery data. 


Category 4 : Identification of only a limited number of special 

features or changes in the image resulting in fur- 
ther reduced data rates. 
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The vast number of data compression techniques reported in the litera- 
ture can be categorized into two groups: 

o Redundancy-reduction-oriented and information-preserving 

encoding schemes such as run coding, block coding, etc., 
which result in a relatively low level of data compaction, 
but which retain all of the information contained in the 
original picture. 

o High-compaction-oriented approximate approaches which 

result in significantly higher levels of data compressions, 
but which sacrifice some of the information. 

The needs of categories III and XV applications are not of much concern 
here because the onboard recognition processing (cluster coding) envisaged for 
these applications automatically brings down the data rates to reasonable levels. 

Of course, in these applications, the problem of concern is the feasibility of 
such onboard recognition processing in real time. - 

However, the compression ratios attainable under the present state-of- 
the-art, without exceeding tolerable LeveLs (3 percent) of degradation of the imag'e ry, 
fall short of the requirements of categories I and II. -As is illustrated in Table 6-3 
the first category of applications calls for approaches which are essentially 
information -preserving approaches, such as encoding schemes. While the 
actual compression ratios attainable under any approach is application or data 
dependent, the ratios generally achieved by these encoding schemes are rather 
too low to be of significance in the context of the data rates expected in future 
missions. Thus, the needs of applications requiring exact reconstruction of 
imagery represent a technology driver at a basic level; this calls for commu- 
nications technology advancements and/or advancements in data compression 
algorithms. The needs of the category II applications, which require an approx- 
imate reconstruction of imagery, can perhaps, however, be met through more 
efficient implementation of presently known techniques or combinations thereof. 

As discussed above, transform coding (possibly in conjunction with 
predictive coding schemes such as DPCM or projection schemes) is viewed as 
one of the more promising approaches for onboard implementation of imagery 
data compression. This technique can provide a compression ratio of up to 
5:1 when combined with variable length encoding. However, this is still insuf- 
ficient to meet future demands, and, therefore, more complex combinations 
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DATA COMPRESSION: REQUIREMENTS AND CURRENT JLTATUS CHART 


CLASS OF 
APPLICATIONS 
(REQUIRING) 

EXACT RECON- 
STRUCTION OF 
THE ORIGINAL 
IMAGE IN EACH 
CHANNEL ( I 
CATEGORY) 

GOOD APPROX- 
IMATION OF 
THE ORIGINAL 
IMAGE WITH 
LITTLE VISU- 
ALLY PERCEP- 
TIBLE DISTOR- 
TION IN EACH 
CHANNEL (II 
CATEGORY) 


OFS PROJECTED* 
(BY THE 
YEAR 2000) 
COMPRESSION 
RATIO 


CURRENTLY 

AVAILABLE 

APPROACHES 

ENCODING 

SCHEMES 


ASSOCIATED 
nANGE OF 
COMPRESSION 
RATIOS 

1 . 2-2 


IMPLEMENTATION 

COMPLEXITY 

nATING 


DPCM AND OTHER 
APPROXIMATE 
APPROACHES IN A 
STANDALONE 
MODE 

I -D TRANSFORM IN 
SPECTRAL DOMAIN 
COMBINED WITH 
DPCM AND HUFF- 
MAN CODING 


1.4 - 3 


REMARKS 

COMPRESSION RATIOS 
CURRENTLY ATTAINABLE 
TOO SMALL* MAJOR CON- 
CEPTUAL/TEC HNOLOGICAL 
ADVANCEMENTS NEEDED 


THESE APPROACHES BY 
THEMSELVES FALL FAR 
SHORT OF THE REQUIRE- 
MENTS OF THIS CATEGORY 


MOST PROMISING APPROACH 
AS PER TRW STUDY WHICH 
STILL DOES NOT LEAD TO 
DESIRED COMPRESSION 
RATIOS 


OTHER ALTERNA- 
TIVES, SUCH AS Z 
AND 3D TRANSFORMS 
IN SPATIAL (AMD 
SPECTRAL) DOMAIN 
FOLLOWED BY DPCM 
AND ENCODING 
TECHNIQUES, NOT 
EVALUATED BY THE 
TRW STUDY 


NEEDS DETAILED ASSESS- 
MENT AND FURTHER STUDY 
TO DETERMINE THE EFFEC- 
TIVE COMPRESSION RATIOS 
AND IDENTIFY PROBLEMS (IF 
ANY) IN THEIR ONBOARD 
IMPLEMENTATION 


ONLY A R EC- 400 - 2000 CLUSTER CODINO, t 10-100 10 OR MORE FAIRLY HIGH COMPRESSION 

OGNITION MAP CLASSIFICATION, RATIOS ATTAINABLE. HOW* 

(III CATEGORY) CHANGE DETECTION EVER, OTHER ONBOARD 

OR ONLY CER- METHODOLOGIES IMPLEMENTATION FROB- 

TAIN KEY FEA- LEMS AniSE 

TURKS OR 
CHANGES IN 
THE SCENE (IV 

CATEGORY) * _____ 

* OFS PROJECTIONS OF “WHAT WILL B£“ FALL SHORT OF “WHAT IS DESIRED* 1 (IN VIEW OF THE EXPECTED DATA RATES IN 
FUTURE MISSIONS) IN THE FIRST TWO CATEGORIES OF APPLICATIONS, 


Table 6-3 



(including possibly two three-dimensional transforms of the multi spectral 
imagery), along with adaptive concepts, have to be investigated. Also, 
implementation involving two-dimensional transforms in the spatial domain 
do not need, a priori, band-to-band registration and are of value when indivi- 
dual band imagery is needed separately, possibly by different users. The 
scope of this approach for onboard implementation has not been explored 
fully in view of the inherent computational complexities. As for example; 
consider a 1024- by 1024-pixels image. It is obvious the image cannot 
reside in the core of the onboard processor, even with the projected 
advancements in hardware technology. Thus, the process of matrix mani- 
pulations, such as transpositions, which are essential to application of the 
two-dimensional transform to the image matrix, pose a software implemen- 
tation problem. Preliminary assessments derived by an awareness of the 
resource requirements has brought out the existence of a possible Technology 
Driver in terms of a need for improved software procedures for matrix trans- 
position of large matrices. The other Technology Driver of importance to this 
area is high-speed buffering techniques which arise in view of the very high 
data rates expected in future missions. 

In summary, the major Technology Drivers associated with the area of 
data compression are: 

o Efficient large -array (two-dimensional) manipulation procedures. 

o High-speed buffering techniques. 

6 3.3 Automated Intelligence 

The area of automated intelligence is still in an embryonic stage, and 
as such, the system concepts are not yet fully developed. While it has different 
conditions to different disciplines, in the context of space exploration, s automated 
intelligence can be viewed as the ability of systems to automatically adapt their 
behavior to the environment and its characteristics. As for example, it could 
be the ability to make decisions, based on the results of preliminary experi- 
ments about the design of further experiments. In effect, it extends the range 
of human facilities such as sensing, recognition, and decision making to remote 
environments wherein direct real-time manual control is not feasible. Basic 
to such capabilities are the fields of development generally referred to as scene 
analysis and adaptive and learning control systems. Technology associated with 
automated intelligence systems covers many disciplines, and, accordingly, the 
drivers are at different levels; conceptual, algorithmic, and software proce- 
dures. Even with scene analysis, there are distinct hardware and software 
related problems. The software functions associated with automated scene 
analysis, a requisite to automated intelligence, are numerous and still in the 
developmental stage. They range in complexity from simple functions, like 
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the smoothing o£ an image, to complex functions of three-dimensional object 
recognition and total scene descriptions using picture grammars and related 
languages. There is a growing body of literature on techniques and algorithms 
to perform these functions. Thus, one can visualize an impressive array of 
individual pieces of software being available for the analyst. However, the 
major problem would be to develop an efficient system which will be capable 
of adaptive selection and deployment of these individual functions to suit the 
environmental needs and constraints. While the interest in the individual 
disciplines ensure progress in all those areas related to automated intelli- 
gence, the requirements of the space-related activities require coodination 
of these developments. In terms of software technology, this translates into 
pursuing the design and control of adaptive procedures. 

In summary, the major Technology Driver associated with automated 
intelligence is the design and control of adaptive software procedures. 



7. 


FUTURE PLANS 


7. 1 Phase I 


Completion of Phase I has established the data base and background 
information required to begin the final phases of the payload software study. 
Figure 7-1 depicts completed activities (crosshatched area) and the activities 
yet to be performed. 

Coordination of activities and sharing of results with the NASA 
Centers, as well as interfacing with other on-going studies within MSFC, 
will be a con tinuin g effort. Travel during the final phases will be dictated 
by needs. 

7.2 Phase H 


Phase II was initiated the last week of November 1976. Phase II 
represents a consolidation and evaluation of the large amount of data 
accumulated in Phase I as preparation for the final Phase IH activity which 
centers on generation of technology development plans. Specifically, 

Phase II will consist of the following items: 

o Detailed analysis of Technology Drivers. 

o Derivation/ evaluation of Technology Items. 

o Merging unique automated payloads data into the data base 

as it becomes available. 

7.3 Phase m 

Phase III is the culmination of the current study. Activities for this 
phase will be: 

o Cost/ time /priority assessment of software Technology 

Items. 

o Technology development analysis, 

o Technology development planning guide preparation, 

o Publication of final report. 

7. 4 Added Effort 

Another effort, not originally part of the Payload Software Technology 
Study but closely related, is an analysis of the Spacelab flight 1 and 2 AO 
responses for additional software Technology Items. 
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APPENDIX A - MISCELLANEOUS 


DEFINITION OF TERMS 


EXPERIMENT 

A CONTROLLED PROCEDURE CARRIED OUT TO DISCOVER, TEST, 

OR DEMONSTRATE THROUGH THE USE OF A GROUP OF RELATED OR 
COMPLEMENTARY INSTRUMENTS, USED IN VARIOUS COMBINATIONS 
AND OPERATING MODES, TO COLLECT DATA PERTAINING TO SPECIFIC 
ASPECTS OF THEIR DOMAIN. 


INSTRUMENT 

A DEVICE FOR MEASURING AND SOMETIMES RECORDING THE 
VALUE OF A QUANTITY UNDER OBSERVATION. 

INSTRUMENTATION 

THE HARDWARE COMPONENTS USED FOR DETECTION, OBSERVATION, DATA 
COLLECTION MEASUREMENT, AUTOMATIC CONTROL, AUTOMATIC COMPU- 
TATION, COMMUNICATION OR DATA PROCESSING IN SUPPORT OF OUR 
EXPERIMENT OBJECTIVE. 


SENSOR 

THE GENERIC NAME OF A DEVICE THAT SENSES EITHER THE ABSOLUTE 
VALUE OR A CHANGE IN A PHYSICAL QUANTITY (E. G. , PARAMETERS 
SUCH AS TEMPERATURE, PRESSURE, OR THE INTENSITY OF LIGHT, 
SOUND, OR RF) AND CONVERTS THAT VALUE OR CHANGE INTO A USEFUL 
INPUT SIGNAL FOR AN INFORMATION GATHERING SYSTEM. 


DETECTOR 

DETECTS THE PRESENCE OR ABSENCE OF A PHYSICAL QUANTITY, 
SUCH AS RADIATION, CHEMICALS, ETC. 


DEFINITION OF TERMS (CONTINUED) 


PAYLOAD ELEMENT 

A RELATED COMPLEMENT OF INSTRUMENTS, SPACE HARDWARE AND 
SOFTWARE CARRIED TO SPACE TO ACCOMPLISH A MISSION OR DISCRETE 
ACTIVITY. CAN CONTAIN ONE OR MORE EXPERIMENTS. 


INSTRUMENT FACILITY 

A GENERAL-PURPOSE DEVICE CONTAINING MULTIPLE SENSORS AND 
DETECTORS TO SUPPORT THE PURSUIT OF SCIENTIFIC DATA WITHIN 
A GIVEN DISCIPLINE. 


PAYLOAD 

ONE OR MORE PAYLOAD ELEMENTS, EITHER AUTOMATED OR SORTIE, 
CARRIED TO SPACE BY THE SPACE TRANSPORTATION SYSTEM. 


FLIGHT 

TRANSPORT OF ONE PAYLOAD TO SPACE. 


MISSION 

THE PERFORMANCE OF A COHERENT SET OF INVESTIGATIONS OR 
OPERATIONS IN SPACE TO ACHIEVE PROGRAM GOALS OR OBJECTIVES (ONE 
OR MORE FLIGHTS). 
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EXPERIMENT ANALYSIS TASK FLOW 




SPDA 


EXTRACT 


IDENTIFY 

LEVEL B 1 
JDATA^^- 


-PAYL. ELEMEI 

TS c. 

SENSOR/ 


-EXPERIMENTS 


DETECTOR 


-INSTRUMENT 


REQUIREMENTS 


» SPECTRAL RANGE 
a BANDWIDTH 
e SENSITIVITY - 
9 ETC, 
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SOFTWARE FUNCTION SIZING 


CORRELATED WITH AVAILABLE DATA WHERE POSSIBLE. 


NEXT GENERATION ON-BOARD PROCESSING FUNCTIONS SIZED WITH ASSUMED 
LIMITATIONS MAY DIFFER FROM GROUND PROCESSES SIZING. 


FUNCTION SIZING INFORMATION IS "TYPICAL. " SAMM ENTRIES PROVIDE 
"COMPLEXITY FACTOR" WHERE APPROPRIATE. 


OPERATING SYSTEM FUNCTIONS AND FUNCTIONS UNIQUE (BUT RELATIVELY 
MINOR) TO SINGLE EXPERIMENT NOT INCLUDED. 


EXPERIMENT ANALYSIS 
DATA MANAGEMENT SYSTEM ASSUMPTIONS 

i 

a COMPUTATION CAPABILITY 

l COMPUTER PLUS BACKUP, 64K OF MAIN MEMORY EACH - 128K 16-BIT WORDS 
l yj? CYCLE TIME, 340K EQUIVALENT ADDS PER SECOND PER COMPUTER 

a MASS' STORAGE 

TAPE OR EQUIVALENT 
READ/ WRITE CAPABILITY 

❖ • RAPID ACCESS STORAGE 

DRUM, DISK, OR ADVANCED TECHNOLOGY DEVICES (CCD, BUBBLE, 

ELECTRON BEAM) 

MINIMUM 100 MEGABITS CAPACITY 
READ/WRITE 

* e DISPLAYS 

MONITOR /FOV COLOR CRT WITH REFRESH 

ALPHANUMERIC/ GRAPHICS DISPLAY (COLOR CRT, WITH REFRESH) 

« INPUT/OUTPUT 

DATA BUS IMB (440KB EFFECTIVE) 

SUFFICIENT NUMBER OF RAU'S 

DMA 

a INPUT/OUTPUT LIMITATIONS ARE RECOGNIZED, BUT IT IS ASSUMED THAT 

ADVANCING TECHNOLOGY WILL REDUCE OR EVEN REMOVE THESE LIMITATIONS 
THROUGH; 

DISTRIBUTED SYSTEMS 
HIGHER -RATE BUS 


* NOT NOW AVAILABLE ON SPACELAB 
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ON-BOARD APPLICATION SOFTWARE FUNCTIONS - TYPICAL 

COMMAND AND CONTROL, DISPLAY, AND DATA ROUTING, 
e POINTING AND SCANNING. 

© TABLE-ORIENTED SEQUENCE AND MONITOR (INCLUDING C&W). 

9 ANNOTATION AND ENGINEERING UNIT CONVERSION, 

o SENSOR ORIENTED GEOMETRIC CORRECTIONS (IMAGE), 

o DETECTOR CALIBRATION AND CORRECTION. 

• VIDICON FILTER AND CORRECTION. 

© SPECIAL COORDINATE OVERLAYS ON FOV MONITOR. 

i 

© ENHANCEMENT AND FALSE COLOR FOR ANY IMAGING EXPERIMENT. 

» REGISTRATION FOR MULTISPECTAL IMAGES (BAND TO BAND). 

• CLASSIFICATION FOR MU LTISPEC T RAL IMAGES (SCIENCE AND E. O. ). 

® FOURIER ANALYSIS FOR INTERFEROMETERS, SAR, ETC. 

© TRANSFORMS AND DPCM FOR DATA COMPRESSION. 
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DATA ENVIRONMENT SCENARIO VS. SOFTWARE FUNCTION (DESF) MATRIX 
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SOFTWARE FUNCTION 
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DATA COMPRESSION: REQUIREMENTS AND CURRENT STATUS CHART 


CLASS OF 
APPLICATIONS 
(REQUIRING) 

OFS PROJECTED* 
(BY THE 
YEAR 2000) 
COMPRESSION 
RATIO 

CURRENTLY 

AVAILABLE 

APPROACHES 

associated 

RANGE OF 
COMPRESSION 
RATIOS 

IMPLEMENTATION 

COMPLEXITY 

RATING 

REMARKS 

EXACT RECON- 
STRUCTION OF 
THE ORIGINAL 
IMAGE IN EACH 
CHANNEL ( I 
CATEGORY) 

0 

ENCODING 

SCHEMES 

1.2-2 

l 

COMPRESSION RATIOS 
CURRENTLY ATTAINABLE 
TOO SMALL. MAJOR CON- 
CEPTUAL/TECI INO LOGICA L 
ADVANCEMENTS NEEDED 

GOOD APPROX- 
IMATION or 

THIS ORIGINAL 
IMAGE V/mi 
LITTLE VISU- 
ALLY PERCEP- 
TIBLE DISTOR- 
TION IN EACH 
CHANNEL (U 
CATEGORY) 

16 

DPCM AND OTHER 
APPROXIMATE 
APPROACHES IN A 
STANDALONE 
MODE 

1*4 - 3 

2 

THESE APPROACHES RY 
THEMSELVES FALL FAR 
SHORT OF THE REQUIRE- 
MENTS OF THIS CATEGORY 


1-D TRANSFORM IN 
SPECTRAL DOMAIN 
COMBINED WITH 
DPCM AND HUFF- 
MAN CODING 

- 3-5 

* 3 

MOST PROMISING APPROACH 
AS PER TRW STUDY WHICH 
STILL DOES NOT LEAD TO 
DESIRED COMPRESSION 
RATIOS 

' 


OTHER ALTERNA- 
TIVES, SUCH AS 2 
AND 3D TRANSFORMS 
IN SPATIAL (AND 
SPECTRAL) DOMAIN 
FOLLOWED IJY DPCM 
AND ENCODING 
TECHNIQUES, MOT 
EVALUATED uy THE 
TRW STUDY 

7 

6 

NEEDS DETAILED ASSESS- 
MENT AND FURTHER STUDY 
TO DETERMINE THE EFFEC- 
TIVE COMPRESSION RATIOS 
AND IDENTIFY PROBLEMS (IF 
ANY) IN THEIR ONBOARD 
IMPLEMENTATION 

ONLY A REC- 
OGNITION MAP 
(III CATEGORY) 
Oil ONLY CER- 
TAIN KEY FEA- 
TURES OR 
CHANGES IN 
THE SCENE (IV 
CATEGORY) 

400 - 2000 

CLUSTER CODING, , 
CLASSIFICATION, 
CHANGE DETECTION 

methodologies 

10 - 100 

10 OR MORE 

FAIRLY HIGH COMPRESSION 
RATIOS ATTAINABLE. HOW- 
EVER. OTHER ONBOARD 
IMPLEMENTATION PROB- 
LEMS ARISE 


* OFS PROJECTIONS OF "WHAT WILL RE" FALL SHORT OF "WHAT IS DESIRED" (IN VIEW OF THE EXPECTED DATA RATES IN 
FUTURE MISSIONS) IN THE FIRST TWO CATEGORIES OF APPLICATIONS. 























SPACEDAB MISSION 1 (STRAWMAN) 


COMMON FUNCTIONS 

INST. 

DATA 

Command and Control 

630 

576 

Annotation and Time Tag 

300 

562 

Display 


350 

432 

Monitor 


400 

576 

Convert to Engineering Units 

500 

1024 



2180 

3170 

AP-09-S 

Checkout 

500 

550 


Scanning Control 

520- 

1024 

AP-13-S 

Pointing Control 

600 

36 

EO-Ol-S 

Checkout 

500 

550 


Calibration 

500 

250 


Operation 

1200 

250 


Graphic Display 

400 

2048 

LS-13-S 

Operation 

270 

150 

APE-01 

Checkout 

500 

550 


Operation 

430 

20 


Graphic Display 

400 

2048 

APE-07 

Calibration 

500 

250 


Operation 

360 

72 


Gi’aphic Display 

400 

2048 

.SPE-01 


— 

— 

SPE-80/85 

Operation 

310 

72 

STE-10 

Operation 

780 

82 


Graphic Display 

400 

2048 

ASE-01 


— 

— 

EOE-OI 

Operation 

730 

206 



11480 

15424 


Total 


26904 


COMMON FUNCTIONS 

Command and Control 
Annotation and Time Tag 
Display 
Monitor 

Convert to Engineering Units 
SO-Ol-S./ SO- 1 l-S/54 


SO-Ol-S/SO-l l-S/S-3b 


SO -5 2 


SO-01-S/S-5 


G-vn 


SPACE LAB MISSION 2 (STRAWMAN) 


Checkout 

Pointing Control {IPS) 
Operation 
Graphic Display 
Checkout 

Pointing Control (IPS) 

Scanning Control 

Operation 

Graphic Display 

Checkout 

Pointing Control 

Operation 

Checkout- 

Pointing Control (Minimount) 

Operations 

Checkout 

Operation 


INST. DATA 


630 

576 

300 

562 

350 

432 

400 

576 

500 

1024 

2180 

3170 

500 

550 

600 

36 

1200 

250 

400 

2048 

500 

550 

600 

36 

520 

1024 

1200 

250 

400 

2048 

500 

550 

600 

36 

1200 

250 

560 

550 

600 

36 

1200 

250 

500 

550 

1200 

250 

14400 

12434 


Total 


26834 


SOFTWARE DEVELOPMENT: 


SOFTWARE SYSTEMS 
ARCHITECTURE: 


SOFTWARE APPLICATIONS: 


OAST TECHNOLOGY ITEMS 
(WORKSHOPS 75/76) 

COORDINATION OF NASA R&D IN COMPUTERS AND 
INFORMATION SCIENCE 

SOFTWARE GENERATION AND HUMAN-MACHINE INTERACTION 

SOFTWARE MANAGEMENT 

SOFTWARE VERIFICATION AND VALIDATION 

OPERATIONS LANGUAGES 

EVOLUTIONARY SOFTWARE 

PROGRAMMING METHODOLOGY 

SOFTWARE COMMONALITY 

PROGRAMMING LANGUAGE AND TRANSLATORS 
SIMULATION 
EFFICIENT EMULATION 
AUTOMATED PROGRAMMING 


NETWORKING FOR NASA COMPUTER FACILITY AND SOFTWARE 
SHARING 

MULTIDIMENSIONAL DATA SYSTEMS 
SOFTWARE FOR SYSTEMS INTEGRITY 
INTELLIGENT EXECUTIVE PROGRAMS 
HIGH- VOLUME DATA BUFFERING 
SYSTEM SECURITY SOFTWARE 

r AUTOMATION OF GROUND SUPPORT FUNCTIONS 

INFORMATION EXTRACTION AND DATA COMPRESSION 
RECOGNITION PROCESSING OF IMAGE TYPE DATA ON-BOARD 
SPACECRAFT 

ON-BOARD PREPROCESSING OF MULTISPECTRAL SCANNER 
DATA 

MODULAR PARALLEL PIPELINE PROCESSOR 
MISSION PLANNING AND SCHEDULING TOOLS 
PATTERN RECOGNITION 

AUTONOMOUS SYSTEMS WITH ARTIFICIAL INTELLIGENCE 

ALGORITHMS/NUMERICS 

AUTOMATED INTELLIGENCE SUPPORT 


MIDTERM REPORT OUTLINE 


SECTION 1 - INTRODUCTION DESCRIBES THE PURPOSE OF THIS REPORT, THE STATUS OF THE 
STUDY AND THE MANNER IN WHICH THIS REPORT IS ORGANIZED. 

SECTION 2 - STUDY SUMMARY IS THE EXECUTIVE SUMMARY. 

2. 1 OBJECTIVES DESCRIBES THE PURPOSE AND SCOPE OF THE STUDY. 

2. 2 APPROACH DESCRIBES THE STUDY PLAN USED AND THE ASSOCIATED MAJOR MILESTONES. 

2. 3 RESULTS SUMMARIZES THE RESULTS OF THE STUDY. 

SECTION 3 - PAYLOAD SELECTION DESCRIBES THE RATIONAL FOR SELECTION OF THE SPECIFIC 
COMPLEMENT OF EXPERIMENTS ANALYZED DURING THE STUDY. 

SECTION 4 - SPACE TECHNOLOGY FORECASTS REVIEW DESCRIBES THE IDENTIFICATION AND 
CLASSIFICATION OF SOFTWARE TECHNOLOGY AREAS SELECTED FOR EMPHASIS. 

SECTION 5 - EXPERIMENT ANALYSIS DESCRIBES THE APPROACH AND MATERIAL USED TO 
PERFORM THE EXPERIMENT ANALYSIS AND SUMMARIZES THE RESULTS. 

SECTION 6 - TECHNOLOGY DRIVER SELECTION SUMMARIZES THE TECHNOLOGY DRIVERS 
SELECTED AND THE REASONS FOR THEIR SELECTION. 

SECTION 7 - FUTURE PLANS DESCRIBES THE EFFORTS REMAINING TO BE PERFORMED UNDER 
THIS CONTRACT. 

APPENDIX A - SOFTWARE FUNCTIONS PROVIDES A COMPLETE DESCRIPTION OF THE DERIVED • 
EXPERIMENT SOFTWARE FUNCTIONS AND THEIR SIZING PARAMETERS. 

APPENDIX B - EXPERIMENT ANALYSIS SHEETS CONTAINS SHEETS FOR EACH ANALYZED PAYLOAD 
ELEMENT AND THEIR ASSOCIATED EXPERIMENTS DESCRIBING MAJOR COMPONENTS, DATA 
CHARACTERISTICS, AND FUNCTIONS TO BE PERFORMED. 
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SOFTWARE ANALYSIS MASTER MATRIX 
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